思想

极限编程是指将最佳实践做到极限

防御性测试代价太大, 应该只测试 80%的正确业务场景

git 规范

git commit 提现业务价值

命名

测试方法名称使用下划线方式命名

命名使用一般含义而非具体实现来命名

写完方法名后让队友读一下以检测可读性

TDD

Why TDD

简化设计

活文档

测试用例维护好后方法签名本身就是活文档

快速反馈

安全保障

测试替身

正交分解法

Code Review 原则

关注 git commits

每个测试通过都要提交一次代码. 至少 30 秒一次提交

commit 粒度:

1. 经验丰富的开发人员: 15m
2. 经验不足的开发人员: 2h

Story 拆分

架构

1. 对请求和响应的处理放在 controller 层

PS: 1 个架构师带 8 个新人

功能

1. 识别 MVP(最重要部分)

   1. 点到点走通
   2. 阻断性功能

半白盒测试

某些单元测试是半白盒的

某些测试依赖于功能的关键实现点. 比如随机数生成

重构过程中发现 bug 暂不进行更改. 重构后再进行

模块中某个单词只能代表一个含义

重构

性能优化非重构

书籍:

1. 程序员修炼之道
2. 架构整洁之道

不重构的情况

1. 不动不看
2. 不知目标: 不知道什么才是好的
3. 不如重写

如何重构

1. 旧的不变
2. 新的创建
3. 一步切换: 注释旧代码, 切换到新代码
4. 旧的再见: 删除旧代码

继承体系不能过长

最好不超过三层

遗留系统重构

获取测试人员的测试清单. 想办法转为单元测试

一部分一部分的重构

优先重构依赖少价值高的代码

副作用

尽量不要写有副作用的函数

副作用: 对输入没有更改

纯函数: 没有状态

只能修改自己类的东西

如何下手

1. 掌握系统业务
2. 明确系统边界
3. 小步改造系统

系统架构可视化工具: C4 模型

1. 系统上下文图
2. 容器图
3. 组件图
4. 代码图